home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19980424-19980901
/
000117_news@newsmaster….columbia.edu _Fri May 22 13:22:11 1998.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
4KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id NAA22331
for <kermit.misc@watsun.cc.columbia.edu>; Fri, 22 May 1998 13:22:08 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id NAA03381
for kermit.misc@watsun; Fri, 22 May 1998 13:22:08 -0400 (EDT)
Path: news.columbia.edu!panix!nntprelay.mathworks.com!cam-news-hub1.bbnplanet.com!wtn-news-feed2.bbnplanet.com!news.bbnplanet.com!netnews.jhuapl.edu!usenet
From: Skip Collins <collibf1@jhuapl.edu>
Newsgroups: comp.protocols.kermit.misc,comp.sys.hp48
Subject: Re: Kermit on the HP48 (Was: One-Way Transfer)
Date: 22 May 1998 13:11:56 -0400
Organization: Johns Hopkins University Applied Physics Lab, Laurel, MD, USA
Lines: 61
Sender: collibf1@COLLIBF1
Message-ID: <wk67iy1b8j.fsf@jhuapl.edu>
References: <35646665.EBB3868B@theriver.com> <6k1qoj$d92$1@apakabar.cc.columbia.edu> <wkvhqye9g4.fsf@jhuapl.edu> <6k42pd$a3m$1@apakabar.cc.columbia.edu>
NNTP-Posting-Host: collibf1-2.jhuapl.edu
X-Newsreader: Gnus v5.5/Emacs 20.2
Xref: news.columbia.edu comp.protocols.kermit.misc:8770 comp.sys.hp48:81325
fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
> But we usually find that what works for us fails to work for others, or vice
> versa. No doubt because there are many and varied HP-48 models, ROM
> versions, etc etc.
I should have noted that I am using an HP48GX with ROM R, the latest.
> 1. The top serial speed is 9600, right?
As far as the built-in kermit is concerned this it true. But there are
user programs that claim to support 19.2k. I have not tried them.
> 2. Should the flow control setting be NONE or XON/XOFF? We have
> conflicting reports (see above). Obviously the HP-48 *should* be
> exercising some form of flow control, but some reports indicate that
> it does not (even if it is set to do so).
Why is flow control necessary or even desirable given the maximum
packet size is 94 and the receive buffer is 255?
> 3. Is the link transparent to incoming control characters? Can the
> client Kermit program use control-character unprefixing when sending
> to the HP-48? If not, the client program must be told to
> SET CONTROL PREFIX ALL prior to sending files to the HP-48.
Shouldn't control char unprefixing be a negotiated feature? If it is
not, I can see where this might be the cause of many people's
problems. Surely it is not the default? I think the physical link is
transparent to control characters. But perhaps the hp48 kermit
software assumes prefixing.
> 4. Does the link allow 8-bit data? If not, the client must be given
> the appropriate SET PARITY command.
Yes, the link allows 8-bit data.
> The HP-48 does not support long packets; thus the maximum packet length
> is 94, but this should be negotiated automatically.
It is negotiated. As far as I can tell, the only "advanced" feature
supported by the hp48 is a choice of block checking options 1, 2, or 3.
> The HP communication port is half duplex, meaning that data can go in both
> directions, but only in one direction at a time. Therefore sliding windows
> can not be used (this too should be negotiated automatically).
The serial port is full duplex. The infrared port is only half-duplex
because of optical feedback. The hp48 kermit certainly has not
implemented sliding windows. There would be very little advantage to
doing so for most users who only use a short cable to connect to a PC.
> Postings on comp.sys.hp48 indicate that the HP-48 Kermit implementation
> "parses" incoming text-mode material on the fly, and appends the material
> from each incoming packet to a "string", resulting in a steadily
> deteriorating transfer rate, at least up to some point at which the HP-48
> dumps the string to storage and starts over with a new string. There's not
> much that the Kermit client can do about that.
This is the biggest problem with hp48 kermit.
Skip Collins